With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet Protocol) have been developed to support the usage of multimedia services. A multitude of different mobile and fixed terminals capable of multimedia communication are also emerging on the market. New services are also constantly being developed for terminal users to increase the field of usage and enhance the quality of experience when generally consuming multimedia services.
An architecture called “IP Multimedia Subsystem” (IMS) has been developed as a platform for enabling multimedia services and sessions, commonly referred to as an IMS network, which can be used to initiate and control multimedia sessions for user terminals connected to various different access networks. Multimedia sessions are handled by specific session control nodes in the IMS network, including the nodes called P-CSCF (Proxy Call Session Control Function) and S-CSCF (Serving Call Session Control Function). Further, a database node HSS (Home Subscriber Server) stores subscriber and authentication data, and different application servers are used for delivering the multimedia services.
The signalling protocol called “SIP” (Session Initiation Protocol) is commonly used for handling multimedia sessions in IMS networks and other service networks. IMS is mentioned in this description for illustrative purposes, without limiting the invention to IMS networks exclusively. A user and his/her communication equipment is often referred to as a “client”, which term will be used here.
A particular example of IMS enabled services is “presence” services, involving publication of presence data of a client to make it available to other clients or applications. Presence data basically refers to the status or state of the client, e.g. including the client's current geographical position, connection status and terminal capabilities, as well as any personal characteristics, preferences and settings. Presence information can be stored in a presence server in the IMS network, based on the publication of client related information. Such publications may be obtained either from the client's terminal or from the used network, whenever any presence data of the client becomes available or is updated.
A client may also subscribe for selected presence data of one or more other clients, e.g. according to a predefined list of an established client group sharing such presence data. Presence subscriptions are typically also handled by a presence server and may involve various information filters, admission rules and policies. The subscribing client can then receive notifications from the presence server regarding current presence data, either automatically or upon request.
In SIP, a message called “SIP PUBLISH” can be used by clients to provide data to the presence server. Further, a message called “SIP SUBSCRIBE” can be used by clients to subscribe for presence data of other clients, as handled by the presence server. Another message called “SIP NOTIFY” can be used by presence servers to present presence data to subscribing clients.
Solutions have also been devised for creating and providing relevant and potentially attractive services that are adapted to different service users according to their interests and assumed needs in different situations. It is therefore useful to identify the current overall situation of a service user, commonly referred to as the “context”. So-called context information may include the presence information or data above, as well as available services, resources and network connections. It has also been proposed to extend the context information to include various measured or computed parameters such as service usage history and parameters related to the current environment such as temperature, ambient sounds, proximity to other clients, etc. In this description, the term “context information” generally represents any information related to a communication entity and his/her current situation, such as the above information types, although without being limited thereto.
In a peer-to-peer system with two or more communication entities, each entity has its own individual context. In this description, a communication entity may be a client terminal, a network server or other node, without limitation. Further, the term “peer-to-peer system” generally refers to a set of communication entities which communicate on a peer basis as opposed to, e.g., client-server communication.
The nodes in the peer-to-peer system make up a group for which a group context can be identified by aggregating the individual contexts of the group members. Various services can then be adapted to the shared characteristics of the group. WO 06/115442 discloses mechanisms where the assumed needs of a user group can be met by providing relevant context information that has been adapted to particular interests and needs of the group.
A concept has also been developed to provide refined information regarding clients, e.g. to increase the usability of applications for invoked services depending on the client's current context or behaviour. It may thus be valuable to use “context-aware” applications to optimally adapt services to the prevailing context of a client. A context server may then be used to collect information about the client by receiving client data from various sources, such as “sensors” or the like adapted to measure or register various variables or the like characterising the current state, status or situation of the client, e.g. temperature or geographical position.
The currently available mechanisms for providing presence data and context data for a client of interest to a requesting party are illustrated schematically in FIG. 1. The client of interest 100 is a user of a mobile terminal T that frequently sends dynamic data, or event publications, to a presence server 102 basically as described above, e.g. in SIP PUBLISH messages using an IMS network (not shown). The presence server 102 may in turn send notifications to the requesting party 104, e.g. a subscribing client, regarding current presence data, e.g. in SIP NOTIFY messages.
In addition or alternatively, one or more sensors 106 may be arranged as described above to provide “raw”, i.e. non-processed, context data to a context server 108, the data being received and stored in a context storage unit 108a. For example, raw context data from sensors may be GPS (Global Positioning System) data which can be translated into geographical information. The shown sensors 106 may also represent functions reflecting client activities in the terminal T or in the used network, not shown. Moreover, existing routines in the communication network for generating call data records for clients can also be used to provide context data.
The stored raw data may then be processed and refined in a context refiner 108b by applying predefined rules 108c on the raw data, in order to derive or calculate new refined context information from the raw data. The predefined rules 108c may include algorithms or the like that calculate certain parameters, draw conclusions or create compilations from the raw data. The refined context can then be distributed to the requesting party 104 according to conventional routines, not described here further.
Typically, context information pertains to an individual client who has a certain profile. However, a client may also belong to an established group of clients, having an aggregated profile shared by its members. For example, members of a family group may have individual contexts while the family may have a common context and an aggregated profile shared by its members, whereas another group specifically interested in, e.g., football games may have a completely different profile.
The context information of a communication entity can be used to determine the relevance of various elements to the entity in communication with other entities or services. Such relevance may relate to the choice of services in applications, the choice of content to be exchanged by these services, their mode of operation, and so forth. Hence, it may be useful to have relevant context information available when creating and providing services and media to clients and other entities. Entities belonging to different communication groups may thus observe various context information of each other, e.g. including information originating from various sensors. Technically, the context of one entity could also include context information on other related entities.
As mentioned above, communication services and media can be adapted and provided in a system with plural entity peers based on the individual contexts of the entities, which can be aggregated into a group context. Furthermore, it may be desirable to create an optimised topology of communication entity peers, considering the contexts above, and to facilitate interconnections between the entities. If this could be accomplished, more attractive services may be possible involving efficient media transport between the entities, e.g. over short connections and/or using links and terminals with suitable characteristics and abilities.
However, the individual contexts of the entities in such a group typically fluctuate and change over time more or less randomly, e.g. when individual entities are reconfigured or change their status, or when certain services gain or lose popularity, and so forth. As a result, the aggregated group context will also change accordingly. Entities may also come and go unpredictably. Therefore, services and media that have been adapted to a group context more or less statically may well become unsuitable or irrelevant in some respect, due to the changing individual contexts. Moreover, a created network topology for shared communication and service usage may not be optimal or even useful anymore. It can be readily understood that it is not an easy task to manage a system with plural entity peers properly from the central service node and keep it up-to-date, to provide suitable or optimal services and media.